Engineering Rules

 

This appendix provides engineering guidelines for configuring the system to meet network deployment requirements.

This appendix consists of the following topics:

•	CLI Session Rules

•	ASR 5000 Interface and Port Rules

•	ASR 5000 Packet Processing Card Rules

•	Context Rules

•	Subscriber Rules

•	Service Rules

•	Access Control List (ACL) Engineering Rules

CLI Session Rules

Multiple CLI session support is based on the amount of available memory. The Resource Manager reserves enough resources to support a minimum of six CLI sessions at all times. One of the six sessions is further reserved for use exclusively by a CLI session on an SPIO serial interface.

Additional CLI sessions beyond the pre-reserved limit are permitted if sufficient SMC resources are available. If the Resource Manager is unable to reserve resources for a CLI session beyond those that are pre-reserved, users with administrator-privileges are prompted to create the new CLI session, even without reserved resources.

ASR 5000 Interface and Port Rules

The rules discussed in this section pertain to the following Ethernet line cards and their interfaces regardless of the application.

•	Fast Ethernet 10/100 (FELC/FLC2)

•	Gigabit Ethernet 1000 (GELC/GLC2)

•	Quad Gigabit Ethernet (QGLC)

•	10 Gigabit Ethernet Line Card (XGLC)

Line Card Rules

The following engineering rules apply to the Fast Ethernet 10/100, Gigabit Ethernet 1000, Quad Gigabit Ethernet and 10 Gigabit Ethernet line cards:

•	Give all logical interfaces a unique name to identify the interface from others in the same context. Logical interfaces in different contexts may have the same name.

•	A single physical port can support multiple logical interfaces when you configure VLAN tags for that physical port. You can use VLAN tagging to bind a single physical port to multiple logical interfaces that reside in different contexts.

•	Assign all logical interfaces a valid IP address and subnet.

•	Give each logical interface within a context a unique IP address(es). Logical interfaces in different contexts can have the same IP address(es).

•	If multi-homing is supported on the network, you can assign all logical interfaces a single primary IP address and up to 16 secondary IP addresses.

•	You can configure a logical interface in only one context, but you can configure multiple interfaces (up to 512 Ethernet or 1,024 ATM) in a single context.

•	You can apply a maximum of 128 access control list (ACL) rules to a single logical interface.

•	All ports are identified by their <slot#>/<port#>.

•	Each physical port on a Gigabit Ethernet 1000 or Quad Gigabit line card may contain up to a maximum of 1,024 VLAN tags.

•	Each physical port on an Fast Ethernet 10/100 Line card may contain up to a maximum of 256 VLAN tags.

•	The total number of VLANs untagged and/or tagged on each Fast Ethernet 10/100 Line Card must not exceed 1025 (8 untagged + 1,017 tagged).

•	A logical interface is limited to using a single VLAN or ATM PVC on a single physical port, identified by its <cardslot#/port#>.

•	When using redundant (standby) line cards:

•	You must configure the active line card only. In the event of a failover, all relevant information (including the IP address) is transferred to the standby line card.

•	Half-height line cards must installed in the upper and lower chassis slots behind a sa packet processor card must be of the same type: FELC/FLC2,GELC/GLC2, or QGLC line cards.

Important: If you have enabled the Port Redundancy feature, it is possible for ports on both line cards to be active while one provides line card redundancy for the other. With the port redundancy feature, each physical port has a primary MAC address. Each corresponding standby port has a different (alternate) MAC address.

Packet Data Network (PDN) Interface Rules

The following engineering rules apply to the interface to the packet data network (PDN):

•	Configure the logical interfaces used to facilitate the PDN interface within the egress context.

•	The default is to use a single interface within the egress context to facilitate the PDN interface.

•	You can configure multiple interfaces in the egress context by using static routes or dynamic routing protocols.

•	You may also configure next-hop default gateways.

ASR 5000 Packet Processing Card Rules

The following engineering rules apply to the packet processing application cards:

•	Configuring a line card to enter the active mode results in the following:

•	The total number of packet processing cards that will become operationally active is increased by one.

•	In the event of a failure, the line card(s) directly behind the packet processing cards will become available directly, or to another packet processing cards via the RCC.

•	If you want processing-only application cards, all line card slots directly behind the such cards can be empty. Otherwise, disable those line card slots with the shutdown command described in the Command Line Interface Reference.

•

If you want standby (redundant) packet processing cards, do not populate line card slots directly behind them since they will not be used. If the slots are populated, disable the line card slots with the shutdown command as described in the Card Configuration Mode Commands section of the Command Line Interface Reference.

•	A line card will not handle subscriber traffic unless the packet processing card directly in front of it is made active.

Context Rules

•	A maximum of 64 contexts may be configured per chassis.

•

Up to 2000 IP address pools can be configured within a single context (regardless of the number of packet processing cards with a total system limit of 5,000 IP address pools for all contexts. However, there is also a limit of 4,000,000 addresses and 32,000,000 static addresses that can be configured per context. Therefore, the number of pools depends on how many addresses are being used and how they are subnetted.

•	Each context supports up to 32,000,000 static IP pool addresses. You can configure a maximum total of 64 x 32M static IP pool addresses per chassis. Each static IP pool can contain up to 500,000 addresses.

•	Each context supports up to 4,000,000 dynamic IP pool addresses. You can configure a maximum total of 4 x 4M dynamic IP pool addresses per chassis. Each dynamic IP pool can contain up to 500,000 addresses.

Important: Each address in the pool requires approximately 60 bytes of memory. The amount of memory required, however, depends on a number of factors such as the pool type, and hold-timer usage. Therefore, in order to conserve available memory, you may need to limit the number of pools depending on the number of addresses to be configured and the number of installed application cards.

•	The maximum number of simultaneous subscriber sessions is controlled by the installed capacity license for the service(s) supported.

•	The maximum number of static routes that can be configured per context is 1,200.

•	The maximum number of static ARP entries per context is 128.

•	The maximum number of domains per context is 2,048.

•	ASN-GW services configured within the same context cannot communicate with each other.

•	A maximum of 512 BGP/AAA monitors can be configured per context for Interchassis Session Recovery (ICSR) support.

•	You can configure up to 128 AAA servers per context for a default AAA server group. The servers can be configured as accounting, authentication, charging servers, or any combination thereof.

•	You can configure up to 800 AAA server groups per context with following limitations:

•	Configure up to 128 servers per AAA server group. The servers can be configured as accounting, authentication, or charging servers, or any combination thereof.

•	Configure up to 1,600 servers per context in AAA Server group mode. The servers can be configured as accounting, authentication, or charging servers, or any combination thereof.

•	Up to 800 NAS-IP address/NAS identifier (one primary and one secondary per server group) can be configured per context.

•	Up to 12 charging gateway functions (CGFs) for GTPP accounting can be configured per context.

Subscriber Rules

The following engineering rules apply to subscribers configured within the system:

•	Configure a maximum of 2,048 local subscribers per context.

•	You may configure attributes for each local subscriber.

•

The system creates a default subscriber default for each context when the context is made. Configure attributes for each default subscriber. If a AAA-based subscriber is missing attributes in the authentication reply message, the default subscriber attributes in the context where the subscriber was authenticated are used.

Important: Default is not used when local authentication (for local subscribers) is performed.

•	Configure default subscriber templates on a per AAA realm (domain aliases configured within a context) basis.

•	Configure default subscriber templates on a per PDSN, FA, ASN-GW, or HA service.

•	For AAA authenticated subscribers, the selection of local subscriber template to use for setting attributes is in the following order:

•	If the username (NAI) matches any local domain name and the domain name has a local subscriber name configured, that local subscriber template is used.

•	If the first case fails, and if the serving service has a default username configured, that subscriber template is used.

•	If the first two cases fail, the default subscriber template in the AAA context is used.

Service Rules

The following engineering rules apply to services configured within the system:

•	Configure a maximum of 256 services (regardless of type) per system.

Caution: Large numbers of services greatly increase the complexity of management and may affect overall system performance. Therefore, you should not configure a large number of services unless your application absolutely requires it. Please contact your Cisco service representative for more information.

•	The total number of entries per table and per chassis is limited to 256.

•

Although you can use service names that are identical to those configured in different contexts on the same system, this is not a good practice. Services with the same name can lead to confusion and difficulty in troubleshooting problems, and make it difficult to understand the output of show commands.

Access Control List (ACL) Engineering Rules

The following rules apply to Access Control Lists:

•	The maximum number of rules per ACL is 128.

•	The maximum number of ACL rules applied per port is 128.

•	The maximum number of ACL rules applied per context is 1,024.

•	The maximum number of ACL rules per IPSec policy is 1.

•	The maximum number of IPSec ACL rules per context is 1,024.

•	The maximum number of ACLs you can configure per context is limited by the number of rules allowed within each ACL. If each ACL contained the maximum number of rules (128), the maximum number of ACLs per context is 8 (128 X 8 ACLs = 1,024 ACL rules per context).

•	The maximum number of ACLs applied to an IP access group is 1, whether it is configured for a port or context. Since the maximum number of IP access groups you can apply to an interface or context is 16, the following calculations apply:

•	For each interface/port: 8 rules per ACL multiplied by 16 IP access groups = 128 (the ACL rules limit per port)

•	For each context: 64 rules per ACL multiplied by 16 IP access groups = 1,024 (the ACL rules limit per context)

 

 

Cisco Systems Inc.

Tel: 408-526-4000

Fax: 408-527-0883